Network operators use different middlebox services or appliances, called inline services, such as Deep Packet Inspection (DPI), logging, metering, charging, advanced charging, Firewall, Intrusion Detection and Prevention (IDP), and Network Address Translation (NAT), to manage subscribers' traffic. These inline services have high requirements on throughput and packet inspection capabilities. The inline services can be transparent or nontransparent to the end users. Inline services can be hosted in dedicated physical hardware, or in virtual machines.
Service chaining is required if the data traffic needs to go through more than one inline service. As used herein service chaining refers to configuring a sequence of inline services that process a particular flow of the data traffic traversing a network administer by a network operator. Moreover, if more than one chain of services is possible, then the network operator needs to configure the networking infrastructure to direct the data traffic associated with a particular flow through the correct inline service path. As used herein, ‘traffic steering’ refers to directing the forwarding of the data traffic of a flow through an inline service path specified for that data flow. A flow or data flow as used herein refers a set of data that has a common source and destination.
Steering traffic to provide inline service chaining can be implemented using a set of rules or configuration mechanisms to direct the forwarding of the data traffic to each middlebox or similar networking device implementing the inline services. These rules and mechanisms are designed to explicitly insert the inline services on a defined path between the end-points of the path (i.e. the source and destination), or to explicitly route traffic through different middleboxes according to a set of predefined network policies in the controller. However, no matter what mechanisms, rules or policies are used to steer traffic in the network, there exists a problem of how to test that the service path is correctly implemented in the network, and how to verify that a flow traverses the configured path for that flow. For example, it is difficult to verify that a flow ‘f’ has indeed traversed a set of services A, B, and C in this specific order but no other services. This problem is referred to as reachability measurement for inline service chaining Although there are operations, administration and management (OAM) tools to measure reachability in general networking settings, the inline services chaining imposes new and specific challenges that render these tool ineffective. The key challenge is that, these general OAM tools actively inject packets to the network to test the wellness of a network path. However, if packets are actively injected to the service path, the packets will be forwarded to the middleboxes implementing the inline services. These middleboxes may not know how to handle these OAM injected data packets, and thus, the middleboxes may drop the unknown packets. Or the data packets may confuse the internal states of the middleboxes thereby impacting the performance of these middleboxes and degrading the inline service.